-
Notifications
You must be signed in to change notification settings - Fork 304
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: Input attrs
not reactive
#228
fix: Input attrs
not reactive
#228
Conversation
Do i have to run |
No, no need to build the registry on your end |
I have thought about attrs wayI think making read-only Proxy (useAttrs, $attrs) reactive is not a good idea We are using computed or maybe toRefs for attrs to make them reactive/can-be-mutated inside the Component, which they can't, we are changing their nature (readonly) props wayBy adding class to props, class will be removed from $attrs object so we will not get duplicated class so we can use props.class in cn function and v-bind="$attrs" without worrying about duplication Even though we are not changing/mutating some props like class (toRefs/computed) inside the Component I think using props is a better way. Sorry for my bad English. I'll try to make a Vue SFC Playground example to explain what I meant |
Yeah i also think using Props is a better approach here. Created a playground for it. Sorry for the late response. |
Just changed one thing in your playground, also thanks for your comment Let's fake imagine class type changes in the feature so using this type from Vue ( - class?: string
+ class?: HTMLAttributes['class'] |
Yeah this is right way to do the typing. I should've used the HTMLAttributes['class']. |
Now, Should i change my implementation to using Props for class? Or there are still some scenarios or edge cases we want to check first? |
Yes, go with Props Please, if you have time, refactor all the components |
Yeah, okay. |
Yes, only useAttrs 🙏 I'll refactor the rest if it's needed |
Change the implementation to using props for |
Fixes: #224